昨天說今天要把這幾天的量測包成可以重跑的東西。

前七天每一次量都是手打指令。麻煩還是其次，真正的問題是兩次量的條件不保證一樣：上次是幾公尺的線、跑了幾筆、bypass-only有沒有開，我只能靠記憶。Day 5 最後那句話今天要兌現：「一模一樣」這件事人做不到，只有把參數寫死在設定檔裡的腳本做得到。

做出來是四個檔。量測拆成兩支腳本，一支量直連、一支量過交換器；判讀跟統計是另外一支程式；參數全部集中在一個設定檔裡。今天上機驗的是量直連那支，過交換器那支要等線接回交換器才驗得了，所以下面所有數字都是直連的。

參數外部化：設定檔是唯一來源

介面名、封包長度、每點幾筆、線材幾公尺、當次的轉發模式，全部在一個 config.yml 裡。腳本自己不帶任何一個數字。跑完之後，那份設定檔會被整份複製進結果目錄，檔名是 config-used.yml。

results/<當次的時間戳>-baseline/
├── config-used.yml      當次的設定，整份複製進來
├── direct_64.csv …      原始資料
└── summary.csv          統計表

這個複本才是重點。Day 5 講過，三個月後翻出一個 60.0，你要知道它是在什麼條件下量的，不然它只是一個數字。判讀腳本也是讀這份複本。少了它，它會直接說「這不是一個量測結果目錄」，不會硬跑給你一個看起來很像答案的東西。

設定檔沒有用 YAML 函式庫。這台機器裝不了額外套件，所以格式退成最平的 key: value，bash 用 grep 加 cut 讀，python 十行解析完。換來的是零相依，只要有 bash 跟 python3 就跑得起來。

前置檢查內建於腳本

有三件事我前七天踩過，現在每次執行都自動做一遍：

bypass-only 重開機會回 off   -> 每次執行重開一次，並且驗證真的開了
python3 在有些系統上是空殼   -> 試跑一次，不用 command -v 判斷
線1長度兩次不一樣            -> 直接拒絕相減

第一條最容易中。不帶 -v 的 exanic-config 看不到 bypass-only 的狀態，所以它關著的時候，你不會收到任何錯誤，只會拿到一組偏掉的數字。第三條是 Day 6 那個推導的前提：線1在相減的時候要抵消，前提是兩次用同一條。

負樣本測試：兩個被抓出來的缺陷

上機之前，我寫了假的 exanic-config 跟 exanic-measure，讓腳本以為自己在跟真設備講話，正樣本負樣本各餵一遍，抓到兩個缺陷。

第一個：某個長度完全沒吐出資料的時候，腳本會裝作沒事。 判斷筆數的那行在變數是空字串時會噴 integer expression expected，而測試不成立就不會進 then，迴圈照跑，最後還印出「結果目錄：…」，失敗的那次跟成功的長得一模一樣。 → 改成先檢查檔案存在而且非空。

第二個： 判斷「延遲有沒有隨封包變長」的時候，我原本拿六個點的總散布當雜訊。資料真的在爬的時候，總散布就等於爬升量本身，所以它永遠會說「訊號沒有大過雜訊」，負樣本一跑就破功。 → 現在比的是各點對擬合線的殘差。

實機執行：六個中位數全為 60.0

驗收條件是 Day 5 對讀者立的那條，中位數必須等於 60.0。

下面這組是三次裡的第二次，每個長度五千筆。

六個長度全部 60.0，門檻過了。

指標重複性：三次重跑，相異值在 5 到 7 之間

Day 3 說巡檢存三個數字就夠：中位數、p99 減中位數、相異值個數。今天是這三個第一次由腳本自動產出。而因為腳本跑一次只要幾分鐘，我順手在兩天之內跑了三次，什麼都沒動，線也沒碰。

          中位數      p99 減中位數        相異值
第一次    60.0 ×6    8 ×5、512 是 12    6 6 6 6 6 6
第二次    60.0 ×6    8 ×6               7 7 7 7 7 7
第三次    60.0 ×6    8 ×6               5 7 5 6 5 5

十八個中位數全部是 60.0，門檻穩得像焊死的。但相異值三次給了三種答案，而且第三次連同一次量測裡的六個長度都對不起來。

Day 3 那篇我寫過：「中位數可以一動也不動，格數卻悄悄變多。」我當時把它當成一個會示警的訊號。跑完這三次才知道，它在什麼都沒發生的時候就會自己動。

回去把十八列對了一次，全部符合同一條算式：

相異值 ＝（最大值 － 最小值）÷ 4 ＋ 1

中間沒有任何一格是空的，所以這個數字根本不是「出現過幾種值」，它是全距換算成格數。那就表示它完全由最極端的那一筆決定。五千筆裡只要有一筆落到 48，它就從 6 變成 7。

任何一個只看極端值的統計量，都不可能從單次結果訂出門檻。 這跟我當初挑錯數字無關，是這個指標本身的性質。

同一篇我還對讀者說了一句：「哪天同一條線變成八格十格，就是抖動變大了。」那個八，是我看著一次量測的五格訂出來的。現在正常狀態就會跑到七格，離告警線只剩一格。 那條門檻訂得太緊，照著用會誤報。

所以這三個數字要分開看：

中位數        可以直接當門檻            三次十八個量測全部 60.0
p99 減中位數  可以，但要留一格的餘裕    大部分是 8，偶爾跳到 12
相異值        不能拿單次結果當基準      什麼都沒動的時候就在 5~7 之間晃

相異值還是值得存，只是它得先有自己的基線。 要拿它告警，門檻得訂在多量幾次之後的上緣之外，而不是某一次的值加一。

平均值那一層是這三次裡唯一看得見細節的。十八個平均落在 60.598 到 61.524 之間，全距 0.926 奈秒，還不到一格（4奈秒）的四分之一。中位數門檻定在 60.0 不會被這種程度的漂移吵醒，這正是它該有的行為。

基線的保存內容與重跑時機

到今天為止，三條門檻都是量出來的，不是猜的：

直連校正   中位數 ＝ 60.0                            不等於就是儀器或線材變了（Day 5）
交換器     363 ± 12 奈秒                             容許帶＝量到的抖動差（Day 6）
轉發模式   1518 bytes 減 64 bytes 的中位數 < 100奈秒  超過就是被切成 store-and-forward（Day 7）

每一條都存成一整個目錄，不是存一個數字。 那份被複製進去的設定檔就是它的條件單。

重跑綁事件不綁時間。 換線、拔插光模組、換 port、主機重開機、任何人動過交換器組態，要重跑一次。沒人動過的期間，每週一次夠了。

改完設定怎麼證明沒弄壞東西： 跑同一支腳本，中位數要對得上，另外兩個數字要落在它們自己的基線範圍內。不要拿單次的相異值當判準——今天跑三次就給了三種答案。

接下來六天會回頭把前面用到的原理講清楚：延遲到底由什麼組成、行情為什麼走多播、cut-through 跟 store-and-forward 的機制，等等。用的數字全部來自前八天量到的東西，不會有新的實測。

明天先講延遲的四塊，以及為什麼裡面只有一塊值得做即時告警。